Workflow Management Systems (WFMS) support the development, execution and monitoring of business processes. A business process specifies a set of work items and their dependencies along with required resources and assigned roles. Within a WFMS environment, the execution of work items is triggered and monitored by the workflow engine, and even performed automatically for some work items—whereas the individual pieces of work might be distributed across a multitude of different computer systems connected by some type of network.
IBM® WebSphere® Business Process Choreographer represents such a typical modern, sophisticated, and powerful workflow management system. It supports the definition of business processes as a process graph via a graphical editor, while using an underlying flow definition language, such as Business Process Execution Language for Web Services (BPEL4WS). In this language, the actual work items are externalized as Web Services, accessible via standardized interfaces that are specified by help of the Web Services Definition Language (WSDL).
Since 2002, the Business Process Execution Language for Web Services (BPEL4WS) is in the very act of becoming the industrial standard for describing distributed business processes. On the one hand, a BPEL business process is a Web service. On the other hand, a BPEL business process interacts with one or more other Web services, which again can be business processes. Such a Web service is called partner of the BPEL process. Each Web service plays a role in a distributed business transaction, i.e. Buyer and Seller, or Producer and Supplier. Given a BPEL business process, in many cases it is useful to generate a ‘blueprint’ process for the other side, which has assured properties like i.e. behavioral compatibility.
The general challenge is to guarantee behavioral compatibility [c.f. Axel Martens: Analyzing Web Service based Business Processes. In: Proc. of Intl. Conf. on Fundamental Approaches to Software Engineering (FASE'05), LNCS 3442, Springer-Verlag] between two interacting processes in an early design period, particularly in situations in which the original process exists already, and the partner process is in a development phase. To illustrate the underlying problem of behavioral compatibility, FIG. 1 depicts a situation wherein two BPEL processes do not work together well although the interfaces between both processes are perfectly compatible.
In more detail, in FIG. 1, the original BPEL process 200 at the right side interacts with a partner process 100 on the left side. The original BPEL process defines a sequence 205 of three activities: receiving the login data 210, making an internal decision 215, and returning the delivery data. The decision distinguishes two cases 220, 225. Each case implements the parallel execution (i.e. 230) of two sequences (i.e. 240, 255), in which also interaction happens. The interaction to the partner is realized via two interfaces 90, 95, which together form a partner link.
The partner process 100 shown on the left side just mirrors the structure of the original BPEL process. After sending the login data 110, the partner makes a decision 115 on its own to act like a premium customer 120 or like a regular customer 125. While his decision is not synchronized with the decision of the original BPEL process, it is crucial to the interaction. Let's assume the partner 100 acts like a premium customer: He sends terms of payment and order, and awaits discount information 150 and confirmation 165. The original BPEL process, however, might treat him like a regular customer 225 because he might have lost his status because it was too long since he last ordered. In that case 235, it acknowledges the order 290 with the standard business conditions (SBC) 295 and awaits the payment 275. Now, both of the processes are waiting and none can continue on its own—a classical deadlock situation. In the result, the behavior of both BPEL processes is not compatible.
Generating a behaviorally compatible partner process is a non-trivial task. A straight-forward approach could possibly be seen in a structural, pure BPEL-based method. The main idea is to analyze the original process' structure and to reflect it. In the end, this yields a so-called “mirrored” partner process, like the one shown in FIG. 1. While this approach would be based on static mapping rules of all BPEL activities, it does not always generate a compatible partner process as the initial example of FIG. 1 has proven.
A second approach is referred to as “communicational” method and is based on a formal, mathematical analysis of the process model. Some details are given in FIG. 2 which shows a block diagram representation of the basic steps of the latter-mentioned prior art partner process generation method. Such prior art method is published at [Axel Martens: Analysis and re-engineering of Web Services. In: Proc. of 6th Intl. Conf. on Enterprise Information Systems (ICEIS'04), Porto, Portugal].
In step A the original process 200 is transformed into a formal input representation 320 as for example Petri Nets, or π-Calculus. This representation is intermediary in nature. It describes formally the internal logic of the original process, and its externally visible communication behavior.
In step B2 the communication behavior of the formal input representation 320 is analyzed. This yields the communication graph that contains all possible sequences of input and output messages that may occur in the given process—the communication model 330 of the given BPEL process. Because some of those possible communication sequences might yield unwanted situations (like deadlocks, c.f. FIG. 1), the partner to generate should avoid those unsound sequences.
In step C the communication graph is restricted and projected to usable behavior. This yields to a sub-graph that represents a controller model 340 for the given BPEL process. Finally, in step D, the controller model, which is a graph, has to be transformed into a process model. The prior art method does perform a generation of a formal process model representation 345, but it does not bridge the gap to the target language BPEL.
On the level of formal process model representations, the communicational method can be proven to produce behaviorally compatible processes—in contrast to the previously mentioned structural method. However, it will consider actually all possible sequences of communication activities. To illustrate that drawback: For a number of 12 communication activities in the original process, there are 12!=47,900,1600 possibilities to order them. The complexity to order the activities of two parallel sequences of the length 8 has an order of 48=65,536. Hence, the method often will yield a partner process that is often too complex to be easily understood by the partner, making it rather hard to refine it, since the process logic might be “distributed” in the generated partner process. This can be assumed to be caused by the mathematical algorithm used within the method. Thus, this prior art method has significant disadvantages for the developer and is not widely accepted, when developing a partner process.
It is thus an objective of the present invention to provide a method for generating a runtime compliant partner process for a given original process, which is easier understandable for a process developer.